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foreword 


This  report  con®^.i^ut^ V1' chaired1  by* Mr°f  Neil  Eastman  of 
Engineering  In.stifu.t®,  f^mLfinqs  of  this  panel  and  upon  advice 
IBM.  After  the  initial  of  ti ^Sttmmnt  private  sector 

of  the  DOD  General  C^nafn1rotnh.aitst]e°t  with  the  Federal  Advisory 
participation  might  *.h  covernment  panel  members  were 

Committee  Act  PL  92-463,  Therefore  the  membership  of 

excused  from  further  9***™***“™-  and  the  findings  must  be 
this  panel  is  non-governmental  and 

interpreted  in  this  light. 

The  members  of  the  panel  have  reviewed  and  endorse  the 
panel  recommendations. 


Thomas  H.  Prober t 

Simp««'and  Software  Engineering  Division 
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PREFACE 


Mission-critical  computer  software  systems  have  been  growing 
larger,  more  complex,  and  much  more  expensive.  The  Electronics 
Industries  Association  has  predicted  that,  at  current 
productivity  levels,  software  will  consume  10%  of  the  defense 
budget  by  1990.  Today,  neither  our  budget  nor  our  technical 
capability  is  adequate  to  support  the  rapid  growth  in 
applications  that  we  are  experiencing.  The  all-too-f requently 
observed  symptoms  ares  (1)  weapon  system  schedule  slips  due  to 
software  problems;  (2)  system  failures  due  to  software  bugs;  (3) 
Software  cost  overruns;  and  (4)  a  nationwide  shortage  of 
software  professionals. 

At  least  six  Defense  Science  Board  Task  Forces  and  USDRE 
independent  review  committees  plus  the  Air  Force  Scientific 
Advisory  Board  have  recently  reinforced  and  emphasized  the  need 
for  extensive,  specific  and  coordinated  DoD  sponsored  software 
activities  to  resolve  the  problems  in  software. 

In  1982,  the  Deputy  Under  Secretary  of  Defense  (R&AT) ,  with  the 
support  of  the  Assistant  Secretary  of  the  Army  (RD&A)  ,  the 
Assistant  Secretary  of  the  Navy  (RE&S) ,  and  the  Assistant 
Secretary  of  the  Air  Force  (RD&L) ,  formed  a  DoD  Joint  Service 
Task  Force  on  software  problems  to  review  the  problems  in  DoD 
Embedded  Computer  Software  and  to  assess  the  impact  these 
problems  have  on  the  U.S.  military  mission.  Their  report, 
completed  in  July  1982,  reinforced  the  view  that  there  are  many 
difficulties  facing  DoD  in  software.  Many  examples  are  cited 
illustrating  that  the  problems  are  severely  affecting  the  cost, 
deployment  schedules,  as  well  as  the  utility  of  deployed  weapon 


iv 


systems.  The  Task  Force  recommended  that  a  comprehensive 
software  initiative  be  undertaken. 

A  Joint  Task  Force,  working  from  October  1982  to  March  1983, 
proposed  a  Strategy  for  the  "Software  Technology  for  Adaptable, 
Reliable  Syste  -s"  (STARS)  program,  to  address  the  critical 
software  situation.  Contained  within  the  report  of  the  Task 
Force  is  a  proposal  for  the  establishment  of  a  Software 
Engineering  Institute  (SEI)  to  bridge  the  gap  between  R&D 
activities  that  demonstrate  new  techniques  and  the  exploitation 
of  those  techniques  in  system  developments  in  order  to  effect  a 
significant  and  rapid  improvement  in  the  means  of  development 
and  support  of  computer  software  for  mission-critical  defense 
systems.  The  Task  Force  also  prepared  a  separate  report 
entitled  "A  Candidate  Strategy  for  the  Software  Engineering 
Institute"  which  discusses  proposed  operational  characteristics 
and  organizational  and  management  alternatives. 

The  establishment  of  such  an  organization  is  a  bold  undertaking. 
To  obtain  an  independent  assessment  of  this  recommendation,  OSD, 
with  the  support  of  the  Services,  formed  a  "Blue  Ribbon"  Panel 
from  industry  and  academia  to  study  whether  or  not  such  an 
institute  was  necessary  and,  if  so,  to  prepare  preliminary 
statements  of  mission  and  function,  and  to  develop  criteria  for 
site  selection.  The  Panel  completed  its  work.  This  report  is 
the  result. 


E.  Lieblein 

Acting  Director 

Computer  &  Software  Systems 
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PREFACE 


SOFTWARE  ENGINEERING  INSTITUTE  STUDY  PANEL 


Charter 


The  purposi  of  the  Software  Engineering  Institute  Study  Pan- 
•1  (SEISP)  Is  to  provide  assistance  to  the  Daputy 
Under-Secretary  of  Dafansa  (Rasaarch  and  Advancad  Technology) 
(DUSDCR&AT))  in  defining  the  mission*  responsibilities  and 
options  for  implementation  of  a  DoD  Software  Engineering 
Institute  as  proposed  in  the  STARS  Joint  Service  Task  Force 
Program  Strategy*  April  1*  1983.  The  Institute  for  Defense 
Analyses  (IDA)  assembled  the  panel  at  the  request  of  the 
DUSD( R&AT ) . 

The  Initial  basis  for  SEISP  deliberations  was  the  Software 
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Strategy  document  issued  by  the  Department  of  Defense*  1  April 
1983.  DUSD ( RS AT )  instructions  to  the  SEISP  were  to  challenge 
any  assumptions  regarding  a  potential  Software  Engineering 
Institute  that  the  SEISP  deemed,  questionable  and  to  recommend 
any  functionally  equivalent  or  alternative  strategies  that 
better  serve  STARS  goals. 


Membership 


The  SEISP  was  composed  of  members  from  the  academic  community 
and  the  private  sector.  Appendix  A  contains  a  list  of  members. 
Representatives  of  the  Department  of  Defense  and  the  Services 
served  in  an  advisory  role. 


Consensus 


The  SEISP  members  unanimously  endorse  the  conclusions  and  rec¬ 
ommendations  contained  in  this  report.  The  first  and  most 
Important  conclusion  is  that  a  Software  Engineering  Institute 
is  essential  to  achieving  STARS  goals  and  must  be  established 
with  the  greatest  possible  speed. 
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1.0  SUMMARY  OF  FINDINGS  AND  RECOMMENDATIONS 


I. I  PRINCIPAL  RECOMMENDATIONS  AND  RATIONALE 


Th«  SE1SP  finds  that  a  Software  Engineering  Institute  is  essen¬ 
tial  to  achieving  STARS  goals  and  must  be  established  with  the 
greatest  possible  speed. 

The  SEISP  accepts  and  reinforces  the  consensus  that  mission 
critical  system  software  is  rapidly  becoming  a  controlling 
factor  in  defense  and  weapon  system  capabilities.  STARS  goals 
are  to  increase  software  productivity  and  simultaneously  to 
significantly  improve  software  adaptability  and  reliability, 
achieving  integral  factors  of  improvement  by  the  end  of  this 
decade.  These  goals  require  major  and  rapid  imprrvements  in 
software  engineering  practice  and  of  necessity  in  the  technol¬ 
ogies  that  enable  improved  practice.  Computer  programming  is 
barely  thirty  years  old  and  only  recently  have  scientific  foun¬ 
dations  begun  to  emerge.  There  is  a  compelling  need  to  develop 
a  mature  discipline  faster  than  has  ever  been  done  before  in 
any  field  of  engineering. 

The  SEISP  is  convinced  of  the  primary  importance  of  software 
techoloov  insertion  in  this  maturing  process.  Promising  tech¬ 
nology  potential  exists  in  universities,  in  research  and 
development  organizations  and  in  commercial  enterprises.  Mis¬ 
sion  critical  applications  impose  severe  requirements  upon 
supporting  technologies  that  few  existing  or  developing  tech¬ 
nologies  can  directly  meet.  Economic  and  societal  factors  tend 
to  damp  rather  than  foster  the  propensity  to  spontaneous  tech¬ 
nological  change.  A  sustained  and  dedicated  effort  to  acceler¬ 
ate  software  technology  insertion  is  required.  High-payoff, 
mutually-supportive  technologies  must  be  selected,  engineered 
to  mission  critical  scale  and  quality  and  applied  as  standard 
practice  throughout  the  MCCR  software  community. 

The  Software  Engineering  Institute  proposed  in  this  report 
must  focus  on  improving  the  actual  practice  of  DoD  software 
development  and  support  by  inserting  modern  technology  into 
the  life-cycle  process.  To  accomplish  its  mission  the  Insti¬ 
tute  willi 

•  Seek  out  appropriate  technology  and  adapt  and  engineer  it 
to  MCCR  production  quality  and  scale 

•  Provide  the  funds,  the  talent  and  the  support  to  selected 
MCCR  projects  to  permit  them  to  utilize  the  best  available 
technology  in  developing  their  software  systems 

•  Establish  a  standard  of  excellence  in  software  engineering 
practice  and  become  a  source  of  top  quality  assistance  and 
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support  for  the  entire  MCCR  development  and  support  commu¬ 
nity 

The  SEISP  recommends  that  a  responsibility  of  maximum  priority 
during  the  first  one  to  two  years  of  Institute  operation  be  to 
establish  an  effective  strategy  for  inserting  technology  into 
private  MCCR  software  contracting  enterprises.  The  avenues 
that  the  Institute  can  exploit  to  influence  DoD  components  are 
much  richer  than  those  available  to  influence  private*  auton¬ 
omous  businesses.  Such  a  strategy  is  on  the  critical  line  of 
Institute  success. 

Approximately  60%  of  Institute  resource  should  be  devoted  to 
achieving  rapid  reduction  to  practice  of  software  engineering 
tools*  methods*  techniques*  processes  and  environments;  20%  of 
resource  should  directly  support  the  Services  and  DoO  compo¬ 
nents*  10%  should  be  dedicated  to  education  and  training  and 
10%  should  be  devoted  to  goal-directed  research. 


1.2  IMPLEMENTATION  RECOMMENDATIONS  AND  CRITERIA 


The  SEISP  recommends  that  a  new  entity  be  created.  No  existing 
organization  was  found  to  be  entirely  adequate  to  assume  Insti¬ 
tute  responsibilities.  The  Institute  should  be  a  dedicated* 
non-profit  corporation,  associated  with  one  or  more  leading 
universities  and  for  the  first  several  years  both  organiza¬ 
tionally  and  geographically  centralized.  Other  institutional 
models  were  considered  and  found  to  be  less  satisfactory. 

Choice  of  location  should  be  guided  by  proximity  to  a  metropol¬ 
itan  area*  a  transportation  hub*  a  university*  rjady  sources  of 
professional  and  support  staff*  ready  availability  of  physical 
plant  and  facilities  and  by  security  from  external  sources  of 
interference  and  intrusion. 

The  DoD  Computer  Software  and  Systems  (CSS)  Directorate  should 
provide  the  focal  point  of  DoD  oversight.  A  Board  of  Visitors 
composed  of  distinguished  technical  leaders  from  universities* 
Industry  and  Government  should  be  appointed  to  assess  Insti¬ 
tute  accomplishments. 

Total  budget  should  be  provided  by  baseline  funding  through  a 
lead-Service  omnibus  contract  supplemented  by  direct  Service 
funding  for  Institute  services  and  products.  The  SEISP  pro¬ 
jects  the  following  staffing  and  budget  levels  as  mlnimums  to 
accomplish  Institute  objectives: 
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YEAR 

l 

2 

3 

4 

S 

6 

Staff 

80 

130 

180 

220 

250 

250 

Baseline  #M 

8 

12 

IS 

20 

20 

20 

Service  *M 

- 

3 

5 

8 

13 

13 

Total  Budget 

“5 

IS 

20 

28 

33 

33 

The  SEISP  explored  four  alternative  Institute  start-up  strate¬ 
gies  but  did  not  sake  an  explicit  selection*  except  to  strongly 
recoamend  that  speed  be  a  priority  consideration. 

Three  issues  critical  to  STARS  success  but  not  critical  to  ini¬ 
tiation  of  the  Software  Engineering  Institute  were  discussed 
but  not  resolvedt  protection  of  proprietary  rights*  pro¬ 
tection  of  militarily  critical  technical  data  and  relation¬ 
ships  with  private  industry. 


Summary  of  Findings  and  Recommendations 


3 


2.0  PROBLEM  STATEMENT 


The  SEISP  accepts  and  reinforces  the  Joint  Service  Task  Force 
conclusion  that  mission  critical  system  software  is  rapidly 
becoming  a  controlling  factor  in  defense  and  weapon  system 
capabilities.  This  report  section  summarizes  the  factors  in 
the  current  situation*  the  future  needs*  the  opportunities  and 
the  impediments  that  form  the  environment  and  the  rationale 
basis  for  the  Software  Engineering  Institute. 


2.1  THE  SOFTWARE  SITUATION 


Excerpts  from  the  Journal  of  Defense  Systems  Acguisitlon  Man¬ 
agement  and  the  STARS  Program  Strategy  outline  a  growing  need* 

"...  an  idea  that  is  only  now  being  realized  -  that  software  is 
a  system.  It  is  no  longer  merely  a  Part  of  a  system*  but  a  sys¬ 
tem  that  performs  the  Integration  functions  for  the  systems* 
whether  they  are  avionics*  or  missiles*  or  command  and  control 
functions.  Integration  of  system  functions  is  now  found  in  the 
information  domain  and*  as  a  result*  ever-increasing  attention 
must  be  given  to  management  to  avoid  the  extension  of  the  soft¬ 
ware  cycle  in  the  normal  pattern."1 

"Software  is  the  essential  element  that  controls,  even 
defines*  the  system.  Software  is  the  embodiment  of  system  "in¬ 
telligence."  In  addition*  it  provides  the  flexibility  to 
respond  to  changing  threats*  needs  and  requirements.  ... 
Development  and  support  of  software  for  major  military  systems 
is  one  of  the  most  complex  of  human  endeavors*  often  requiring 
hundreds  of  people  for  five  or  more  years  at  costs  exceeding 
*100  million  (e.g.*  the  B-l*  Aegis  and  Safeguard  systems).  The 
demand  for  software  is  escalating  rapidly.  Software  is  often 
on  the  system  critical  path*  often  late  and  over  budget  -  the 
costs  for  software  sometimes  even  dominate  the  project  cost. 
To  compound  the  situation*  the  supply  of  trained  professionals 
is  Inadequate .  "2 

Computer  programming  is  barely  thirty  years  old.  Only  recently 
have  scientific  foundations  for  software  engineering  begun  to 
emerge.  But  during  this  thirty  years  there  has  been  an  enor¬ 
mous  programming  population  growth*  accompanied  by  an  equally 
enormous  accumulation  of  software  Inventory  created  by  pro¬ 
gramming  art  rather  than  by  scientific  or  engineering  disci- 


"DoD  Policy  for  ECR*"  H.  Mark  Grove*  Concents  Vol.  5  No.  4, 
Autumn  1 982 . 

STARS  Program  Strategy .  Department  of  Defense,  1  April 
1983*  Executive  Summary 
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Problem  Statement 


pllne.  Of  the  perhaps  fifty  thousand1  programming  people 
Involved  with  defense  software)  only  a  minority  have  had  formal 
exposure  to  recent  software  engineering  ideas.  Of  the  millions 
of  lines  of  software  in  current  defense  systems*  only  the  more 
recent  have  been  created  according  to  modern  software  engi¬ 
neering  principles.  The  past  dominates  the  present*  prevail¬ 
ing  over  new  approaches  and  the  ideas  of  entrants  new  to  the 
community. 

There  is  consensus  throughout  the  industry  that  to  achieve 
major  improvements  in  the  qualities  of  delivered  software* 
there  must  be  major  improvements  in  practice  and*  of  necessity* 
in  the  technologies  that  enable  improved  practice. 

The  goal  of  the  STARS  program  is  to  ”...  improve  software  pro¬ 
ductivity  while  achieving  greater  system  reliability  and 
adaptability."*  Attainment  of  that  goal  is  absolutely  depend¬ 
ent  upon  engineering  software  technologies  to  mission  critical 
requirements  and  inserting  such  technologies  into  universal 
practice . 

Within  the  STARS  fix-year  time  frame* 

•  new  technology  capabilities  must  be  engineered  to  mission 
critical  production  quality  and  scale* 

•  engineered  technologies  must  be  Integrated  into  OoO  organ¬ 
ic  environments  and  industrial  development  environments, 
and 

•  high  standards  of  software  engineering  practice  and  soft¬ 
ware  product  quality  must  be  established  and  required 
throughout  the  Defense  software  community. 


2.2  THE  TECHNOLOGY  SITUATION 


There  is  an  increasing  flow  of  new  and  promising  ideas  for 
software  engineering  technologies  —  methods*  techniques  and 
support  systems  --  but  the  bulk  of  these  are  grown  from  ideal¬ 
istic  rather  than  practical  environments  and  their  utility  is 
demonstrated  on  ”toy”  examples.  Yet  the  greatest  difficulties 
often  lie  in  scaling  demonstration  prototypes  to  system-sized 
applications.  These  difficulties  may  be  even  more  challenging 
than  concept  origination  itself*  but  meeting  the  untidy*  prag¬ 
matic  tests  of  large-scale  application  has  little  theoretic 


Estimated  OoO  MCCR  software  expense  of  <5  -  #6  billion  and 
annual  per-head  costs  in  the  neighborhood  of  <100  thousand 
suggest  on  the  order  of  50*000  software  practitioners. 
STARS  Pronr am  Strategy*  Department  of  Defense,  1  April 
1983*  Executive  Summary 
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appeal.  Software  development  and  support  technologies  devel¬ 
oped  for  internal  purposes  may  exist  in  many  enterprises*  but 
they  are  neither  visible  to  the  Defense  community  nor  likely  to 
be  easily  transportable . 

The  experience  base  of  today's  software  population  lies  in 
practicing  an  immature*  labor  intensive  discipline  to  create 
complex  software  systems  by  manual  effort  and  art.  There  is  at 
least  the  comfort  of  familiarity*  if  not  complete  satisfac¬ 
tion*  with  today's  practical  as  long  as  the  iob  seems  to  get 
done*  stability  is  preferable  to  the  potential  discomfort  of 
change.  Software  professionals  valued  for  their  experience 
have  a  vested  intere.st  in  continuing  the  basis  of  that  experi¬ 
ence.  As  long  as  contracts  are  won  and  deliverables  are 
accepted*  management  perceives  little  recessity  to  invest  in 
upsetting  the  status  quo. 


There  is  a  gulf  between  the  practicing  population  and  the 
potential  of  existing  and  nascent  software  technologies. 
Building  a  bridge  between  these  two  worlds  is  the  challenge  of 
jLflf  .taurji  ts.ctmfllpflv  laa.fl.rtlflfu 


2.3  SOFTWARE  TECHNOLOGY  INSERTION 


The  SEISP  is  convinced  of  the  primary  importance  of  software 
technology  insertion .  This  section  outlines  the  SEISP’s 
understanding  of  the  necessary  elements  of  the  software  tech¬ 
nology  insertion  process. 

The  process  has  two  origination  pointsi  a  need  that  stimulates 
the  search  for  and  engineering  of  technology  that  satisfies  the 
need*  or  a  recognition  of  a  technology  capability  that  may 
bring  novel  improvements  in  areas  where  practitioners  have  not 
yet  precisely  articulated  needs.  In  both  cases*  the  decision 
to  initiate  the  process  must  be  governed  by  assessment  of  the 
value  of  the  technology  in  practice. 

Regardless  of  stimulus*  the  technology  Insertion  process  fol¬ 
lows  essentially  this  courses 

•  adaptation  and  engineering  of  the  technology  to  MCCR  pro¬ 
duction  quality  and  scale* 

•  identification*  guidance  and  support  of  initial  users* 

•  evaluation  of  the  results  of  initial  use*  and 

•  expansion  and  support  of  the  using  community. 

The  process  must  draw  upon  an  extensive  pool  of  technology  to 
select  and  to  develop  appropriate  solutions  to  specific  needs. 
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A  new  capability  nay  arise  from  anywhere  within  the  software 
community!  sources  may  range  from  publication  of  research 
results  to  the  appearance  of  a  novel  commercial  product.  Par¬ 
ticularly  In  the  case  of  new  capabilities*  insertion  opportu¬ 
nities  and  payoff  potential  may  be  difficult  to  calibrate  with 
metric  precision.  Selection  of  the  most  promising  opportu¬ 
nities  for  full  scale  development  requires  continuing  assess¬ 
ment  and  expert  judgment. 

The  potential  user  base  is  well  known  for  need-driven 
insertion.  For  capability-driven  insertion*  identification 
and  recruitment  of  an  initial  user  set  is  a  critical  step  in 
testing  and  proving  the  capability's  value.  The  marketing  of 
such  capabilities  is  a  difficult  task  that  most  military  and 
Government  organizations  are  not  naturally  equipped  to  accom¬ 
plish!  effective  liaison  with  Service  and  DoD  component  organ¬ 
izations  is  required  to  spread  awareness  of  availability  and 
value . 

Evaluation  of  the  results  of  initial  use  is  essential  for 
understanding  the  strengths  and  weaknesses  of  a  technology  in 
production.  Not  all  technologies  will  survive  the  tests  of 
use.  Those  that  fall  oust  be  quickly  identified  to  prevent 
continued  absorption  of  scarce  resources!  those  that  succeed 
must  be  rapidly  spread  throughout  the  potential  user  community 
on  the  basis  of  tangible  measures  of  success.  Creation  of 
appropriate  measurement  techniques  and  tools  is  an  important 
early  element  in  the  insertion  process. 

Expansion  of  the  user  base  by  dissemination  of  proven  technolo¬ 
gies  is  the  next  essential  stage.  Technology  that  has  bean 
successfully  transferred  to  MCCR  applications  will  require 
monitoring  to  assure  continuity;  the  expanding  user  base  will 
need  continuing  support  for  effective  application  and  will 
provide  feedback  for  continuing  improvements. 

The  technology  Insertion  process  has  yielded  its  full  value 
when  all  potential  users  have  become  actual*  effective  users. 


2.4  IMPEDIMENTS  TO  TECHNOLOGY  INSERTION 


Mission  critical  applications  impose  severe  requirements  upon 
supporting  technologies  that  few  existing  or  developing  tech¬ 
nologies  can  meet. 

Commercial  software  technologies  are  not  always  directly 
applicable  in  mission  critical  software  development  and  sup¬ 
port.  Although  commercial  systems  (e.g.*  communications 
switching*  large-scale  scientific  computations*  process  con¬ 
trol*  financial  management)  may  share  some  of  the  Character- 
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lstics.  stringent  requirements  ere  often  simultaneously 
Imposed  upon  MCCR  systems. 


•  Size  and  complexity  may  be  an  order  of  magnitude  larger  in 
mission  critical  systems  than  in  those  considered  large  by 
commercial  standards;  MCCR  systems  containing  several  mil¬ 
lions  of  instructions  are  not  uncommon. 

•  Real-time  response  in  the  microsecond  range  is  necessary 
to  many  missions  while  millisecond  measures  are  usually 
the  norm  in  non-MCCR  applications. 

•  Operational  environments  of  MCCR  systems  are  frequently 
bare  and  remote  from  the  well-supported  host  environments 
in  which  the  software  was  created. 

•  Reliability  requirements  are  stringent  to  the  extreme  for 
MCCR  systems.  Whereas  failure  of  a  commercial  system  may 
have  unpleasant  economic  or  even  life-threatening  conse¬ 
quences.  the  failure  of  a  mission  critical  system  may  well 
imperil  the  defense  of  the  nation. 

Economic  and  societal  factors  create  a  climate  which  damps 

rather  than  fosters  the  propensity  to  spontaneous  change. 

•  Incentives  to  undertake  the  high  cost  of  transferring 
technology  to  MCCR  applications  are  apparently  insuffi¬ 
cient.  The  profit  potential  of  the  DoD  software  market  is 
evidently  not  large  enough  to  offer  inducement  for  soft¬ 
ware  technology  Investments  of  the  needed  magnitude. 

•  Exposure  of  valuable  technology  to  possible  Government 
data  rights  claims  increases  reluctance  to  Invest  in  or  to 
apply  proprietary  technologies. 

•  Risk  is  seen,  rather  than  opportunity,  in  employing  new 
technology  during  MCCR  system  development.  Productivity 
and  quality  improvements  will  occur  only  over  time  as  pay¬ 
backs  such  as  growing  libraries  of  reusable  software 
mature,  whereas  the  risks  or  uncertainties  of  a  new  tech¬ 
nology  are  realized  immediately. 

•  Inertia  is  more  comfortable  than  change.  Present  prac¬ 
tices  are  seen  as  working  -  after  all.  systems  do  get  built 
and  accepted.  Current  development  and  support  methods 
have  a  wide  base  of  accustomed  users  within  OoD  and  indus¬ 
try.  An  impetus  for  change  that  outweighs  the  potential 
discomfort  is  needed. 

•  Insulation .  in  the  sense  that  military  software  developers 
see  themselves  as  a  breed  apart  from  commercial  software 
engineers,  tends  to  lessen  awareness  of  developments  in 
universities,  research  organizations  and  innovative  soft¬ 
ware  products . 
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Agressive  action  is  needed  to  bring  militarily  significant 
softwara  technologies  into  cantral  focus.  As  the  MCCR  acquisi¬ 
tion  systam  is  prasantly  structured*  businass  in  tha  private 
sector  offers  generally  greater  profit  opportunities  than 
defense  businass.  Market  forces  work  against  the  needed  strat¬ 
egy*  new  technology  development  tends  to  gravitate  towards 
more  profitable  commercial  applications  and  markets.  A  sus¬ 
tained  and  dedicated  effort  to  accelerate  technology  insertion 
is  required. 


2.S  THE  TECHNOLOGY  INSERTION  DRIVER 


The  SEISP  strongly  endorses  a  Software  Engineering  Institute 
as  essential  to  the  technology  insertion  component  of  the  STARS 
strategy.  There  is  a  need  to  develop  a  mature  discipline  fast¬ 
er  than  has  ever  been  done  before  in  any  field  of  engineering. 

In  the  judgment  of  SEISP  members*  business  as  usual  approaches* 
although  necessary,  will  be  insufficient  to  effect  fundamental 
changes  in  MCCR  software  development  and  support  within  the 
STARS  time  horizon.  Executive  level  direction  to  DOD  compo¬ 
nents  to  modify  policies  and  procedures  towards  higher  priori¬ 
ties  for  technological  upgrades  is  necessary.  Added  funding 
for  technology-oriented  development  in  Service*  university  and 
industry  laboratories  is  necessary.  Increased  emphasis  upon 
software  technology  in  IR&D  programs  is  necessary.  Refinement 
of  the  requirements  for  adaptability  and  reliability  in  RFP's 
and  contracts  is  necessary.  All  of  these  actions  should  con¬ 
tinue*  but  by  themselves  these  continued  stimuli  for  evolu¬ 
tionary  improvements  are  not  likely  to  produce  integral 
factors  of  improvement  in  productivity*  adaptability  and  reli¬ 
ability  for  software  systems. 

There  may  even  be  countervailing  effects  in  business  as  usual. 
Increased  executive  attention  will  of  course  help*  but  techno¬ 
logical  change  can  neither  be  mandated  nor  legislated*  and 
divergent  partial  solutions  could  reduce  overall  effective¬ 
ness.  Increased  technology  funding  may  elicit  new  concepts* 
but  not  necessarily  reflect  insight  into  essential  MCCR  needs; 
the  end  effect  could  be  a  compounding  of  the  technology 
selection  and  insertion  task.  More  aggressive  operational 
software  requirements  could  reduce  the  pool  of  competitors  if 
the  technology  and  practice  base  to  meet  the  requirements  were 
unavailable . 

A  central  driver  is  needed  toi 

*  Pool  scarce  resources 

*  Provide  goal-directed  technical  management 
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■  Select  high-payoff?  mutually-supportive  technologies 

•  Engineer  selected  technologies  to  mission  critical  seal* 
and  quality 

*  Establish  visibla  standards  of  axctllanca  in  praetica  and 
ansura  that  thay  are  mat  by  tha  whole  HCCR  software  commu¬ 
nity 

There  are  two  challenges  in  these  needs  that  differ  in  kind. 
The  first  is  to  ensure  that  appropriate  technologies  are 
brought  into  being  with  the  capabilities  and  robustness 
required  by  MCCR  applications •  which  will  call  for  talents  and 
strengths  primarily  in  technical  management?  technical  judg¬ 
ment  and  technical  performance.  The  second  challenge  is  to 
ensure  that  appropriate  technologies  are  routinely  employed  in 
the  development  and  support  of  MCCR  software.  As  well  as  tech¬ 
nical  insight?  this  challenge  will  call  for  ingenuity? 
resourcefulness  and  skill  across  whole  spectrum  of  poli¬ 
tical?  economic?  organizational  and  marketing  arenas.  Devel¬ 
oping  and  executing  a  strategy  to  bridge  between  technology 
availability  and  technology  application  especially  within  pri¬ 
vate  contracting  enterprises  is  an  essential  part  of  the  tech¬ 
nology  Insertion  process. 


The  SEISP  members  believe  that  a  Software  Engineering  Insti¬ 
tute?  staffed  by  the  most  competent  professional  minds  that  can 
be  brought  to  bear  on  the  engineering  of  MCCR  software?  ade¬ 
quately  funded?  endorsed  and  supported  by  the  Services  and  DoD 
components?  will  provide  the  driving  force  necessary  for  rapid 
technology  insertion. 
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3.0  SOFTWARE  ENGINEERING  INSTITUTE  MISSION 


The  SEISP  recommends  the  following  Software  Engineering  Insti¬ 
tute  mission  statement: 

"The  Software  Enginaaring  Institute  shall  provide 
the  means  to  bring  the  ablest  professional  minds  and 
the  most  effective  technologies  to  bear  on  rapidly 
Improving  the  qualities  of  operational  software  in 
mission  critical  computer  systems.  The  Institute 
shall  accelerate  the  reduction  to  practice  of  modern 
software  engineering  techniques  and  methods,  and 
shall  promulgate  use  of  modern  methods  and  tech¬ 
niques  throughout  the  mission  critical  computer  sys¬ 
tems  community.  •  The  Institute  shall  establish 
standards  of  excellence  for  software  engineering 
practice . " 

The  mission  statement  emphasizes  three  essential  elements: 

•  Concentration  of  a  critical  mass  of  professional  talent 
and  technology  potential. 

•  Transformation  of  technology  potential  into  usable  and 
effective  methods#  techniques  and  supporting  systems. 

•  Application  of  methods#  techniques  and  supporting  systems 
throughout  the  mission  critical  computer  systems  community 
to  achieve  standards  of  excellence  in  practice. 
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4.0  SOFTWARE  ENGINEERING  INSTITUTE  RESPONSIBILITIES 


The  Software  Engineering  Institute  supports  the  goal  of  an 
improvement  in  the  qualities  of  U.S.  mission  critical  opera¬ 
tional  software  that  establishes  and  maintains  the  clear  supe¬ 
riority  of  U.S.  defense  and  weapon  systems. 

The  Institute's  mission  is  to  contribute  to  that  goal  by  assur¬ 
ing  that  software  engineering  practice  throughout  the  mission 
critical  software  community  achieves  and  maintains  a  high  lev¬ 
el  of  effectiveness. 

To  perform  its  mission,  the  Institute's  principal  responsibil¬ 
ities  will  bet 

•  Identifying  and  assessing  against  needs  and  opportunities 
software  technologies  and  technology  potential  from  all 
sources  worldwide. 

•  Acquiring  and  engineering  high-payoff  technologies  to  mis¬ 
sion  critical  production  standards. 

•  Disseminating  engineered  technologies  throughout  the  mis¬ 
sion  critical  software  community. 

•  Supporting  the  Services  and  DoD  components  in  software 
engineering  matters. 

•  Educating  in  support  of  technology  insertion. 

•  Performing  goal-directed  research. 

The  division  of  Institute  effort  amongst  its  responsibilities 
should  reflect  their  priorities  in  relation  to  desired  end 
results.  The  guidelines  below  are  the  SEXSP's  recommendations 
for  resource  allocation  proportions. 

A  major  portion  of  Institute  resources  should  be  devoted  to  the 
first  three  of  these  responsibilities,  which  together  form  the 
core  of  technology  insertion .  Approximately  40%  of  Institute 
resource  should  be  devoted  to  achieving  rapid  reduction  to 
practice  of  software  engineering  tools,  methods,  techniques, 
processes  and  environments  for  MCCR  software  development  and 
support . 

Approximately  20%  of  Institute  resource  should  be  devoted  to 
direct  software  engineering  support  of  the  Services  and  DoD 
components.  The  support  function  will  be  a  voice  of  technical 
authority  on  the  state  of  the  art  and  the  state  of  the  practice, 
and  will  set  standards  of  excellence  for  practice.  Some  pro¬ 
portion  of  this  resource  will  respond  to  requests  for  consult¬ 
ing  services  and  problem  solving  in  support  of  programmatic 
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Activities*  using  these  activities  as  a  vehicle  for  furthering 
technology  dissemination. 

Approximately  10 ‘i  of  Institute  resource  should  be  directed 
towards  education  and  training.  The  Institute  will  develop  and 
conduct  courses  teaching  the  evolving  state  of  the  art  in  MCCR 
software  engineering.  It  will  serve  as  a  seat  of  influence  on 
software  engineering  curriculum  development  throughout  the 
education  community.  The  education  function  will  also  serve  to 
accumulate  and  disseminate  the  "institutional  memory"  of  the 
MCCR  community. 

Approximately  10%  of  Institute  resource  should  be  devoted  to 
goal-directed  research  in  areas  judged  to  be  of  most  essential 
need  and  of  highest  potential  payoff.  Some  level  of  research 
opportunity  is  needed  to  explore  the  ideas  that  the  Institute's 
high  caliber  of  professional  staff  will  generate.  Selecting 
areas  that  complement  the  capabilities  of  acquired  technolo¬ 
gies  will  add  leverage  to  a  moderate  research  resource. 


4.1  TECHNOLOGY  INSERTION  PRIORITIES 


The  SEISP  believes  that  special  emphasis  needs  to  be  placed 
upon  the  technology  insertion  responsibility  with  regard  to 
private  contracting  enterprises. 

The  needs  for  technology  insertion  in  both  organic  OoD  staffs 
and  in  contracting  enterprises  are  comparable*  to  improve  both 
the  support  of  existing  MCCR  software  inventory  and  the  pro¬ 
duction  of  new  MCCR  software.  But  the  formal  legal*  organiza¬ 
tional  and  economic  separation  between  Government  and  industry 
represents  a  particular  challenge.  The  avenues  that  the  Insti¬ 
tute  can  exploit  to  influence  DoD  components  on  behalf  of  DoO 
objectives  are  much  richer  than  those  that  ar?  available  to 
influence  private*  autonomous  enterprises. 

Therefore  a  responsibility  of  maximum  priority  during  the 
first  one  to  two  years  of  Institute  operation  wax!  ua  to  estab¬ 
lish  an  effective  strategy  for  inserting  technology  into  pri¬ 
vate  MCCR  software  contracting  enterprises.  There  are  no 
direct  links  of  command  and  few  of  exactly  shared  motive 
between  the  DoD  and  private  contractors*  the  Institute  must 
find  effective  connections  between  technology  capability  and 
contractors'  practices  so  as  to  satisfy  the  DoD  need  for  sub¬ 
stantially  improved  MCCR  operational  software.  The  SEISP 
deliberated  at  some  length  over  what  the  elements  of  such  a 
strategy  should  be  and  came  to  the  consensus  that  there  was 
inadequate  time  to  produce  a  definitive  discussion.  Develop¬ 
ment  of  a  complete*  sufficient  strategy  will  require  dedi¬ 
cated*  full-time  attention  of  executive  level  management  at 
the  Institute.  Such  a  strategy  is  on  the  critical  line  of 
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Institute  success*  regardless  of  success  in  engineering  out¬ 
standing  software  technologies >  unless  such  technologies  are 
routinely  employed  in  contracting  enterprises  the  ultimate 
goals  will  not  be  met. 

The  Ada*  program  offers  an  example  of  a  successful  Insertion 
strategy.  The  OoO  announced  its  intentions  clearly*  published 
the  time  frame  for  requiring  Ada  and  funded  base  technology 
development  via  the  AIE  and  ALS  environments.  Industry  has 
responded  to  this  strategy  by  preparing  to  employ  Ada  as  the 
technology  becomes  available  and  in  some  cases  even  appears  to 
be  moving  faster  than  OoO  schedules.  Inserting  technologies 
that  delve  more  deeply  into  internal  software  engineering 
practices  will  entail  greater  challenges.  The  Institute's 
insertion  strategy  must  demonstrate  unequivocally  to  contrac¬ 
tors  that  software  qualities  will  be  required  that  are  unat¬ 
tainable  without  new  technologies  or  their  functional 
equivalents*  and  must  offer  genuine  business  incentives  for 
contractors  to  make  the  necessary  investments  rather  than  to 
withdraw  from  competition. 

Many  of  the  elements  this  strategy  should  contain  are  already 
discussed  in  the  various  functional  area  strategies  of  the 
STARS  Program  Strategy.  The  Software  Engineering  Institute 
will  be  the  central  focus  for  reaching  the  pressure  points  of 
Industrial  practice  and  coordinating  the  necessary  changes  in 
DoO  MCCR  procurement  practices. 


Ada  is  a  registered  trademark  of  the  U.S.  Government  AJPO 
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5.0  IMPLEMENTATION  RECOMMENDATIONS 


Evaluating  tha  most  appropriate  and  efficient  Institute  organ¬ 
ization.  location,  functional  relationships  and  start-up  stra¬ 
tegy  requires  selection  criteria  closely  aligned  with  the 
Institute's  mission  and  responsibilities. 


5.1  ORGANIZATION 


The  SEISP  recommends  that  the  Software  Engineering  Institute 
be  t 

•  A  dedicated  non-profit  corporation 

*  Formally  associated  with  one  or  more  leading  universities 

*  Geographically  and  organizationally  centralized  for  the 
first  several  years 

A  private  non-profit  corporation  will  provide  flexibility  and 
Independence  without  unduly  constraining  avenues  of  DoO  over¬ 
sight  and  technical  review. 

Formal  association  with  one  or  more  leading  universities  will 
enhance  the  Intellectual  environment  and  aid  in  attracting 
high  caliber  staff. 

The  need  for  fast#  effective  start-up  motivates  the  recommen¬ 
dation  that  the  Institute  be  initially  centralized.  Decen¬ 
tralization  options  may  add  to  effectiveness  once  the 
Institute  reaches  steady  state#  but  for  the  critical  early 
years  geographic  and  organizational  centralization  are  neces¬ 
sary  to  concentrate  scarce  essential  skills  and  to  foster  a 
unity  of  polricy  and  purpose. 

The  SEISP  considered  several  alternative  Institutional  models, 
none  of  which  was  completely  satisfactory.  Other  alternatives 
were  t 

•  Private  for-profit  corporation 

•  Federal  contract  research  center  (FCRC) 

*  DoO  component 

♦  Contractual  relationship  with  an  academic  institution  or 
FCRC 

•  Joint  DoO-industry-uni versi ty  organization 
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Organization  undor  Govarnmant  auspices  was  rulad  out  for  two 
raasonsi  first#  bacausa  of  the  need  to  offer  highly  compet¬ 
itive  compensation  to  senior  professionals#  to  maintain  stable 
high-level  executive  positions  over  time  and  to  ensure  uncon¬ 
strained  interchange  between  Government#  industry  and  univer¬ 
sity  people)  and  second#  because  the  time-consuming  nature  of 
Government  processes  conflicts  with  the  need  for  a  functioning 
Institute  in  the  shortest  possible  time.  Private  for-profit 
corporations  entail  tax  complications  and  con¬ 
flict-of-interest  exposures.  Joint  venture  approaches  have 
similar  legal  exposures  compounded  by  anti-trust  consider¬ 
ations.  (Appendix  C  analyzes  five  organizations  as  candidate 
models .  ) 

It  is  important  that  the  Institute  operate  with  a  formal 
relationship  with  one  or  more  leading  universities.  The 
relationship  should  be  mutually  beneficial.  The  Institute 
offers  the  university  a  test  bed  for  software  engineering  con¬ 
cepts  and  technologies#  a  source  of  adjunct  professors*  and 
support  for  university  research.  The  university  offers  the 
Institute  faculty  and  graduate  students  familiar  with  software 
engineering  state  of  art  technology  and  testing  and  review  of 
the  Institute's  product  technologies. 

The  centralized  approach  was  chosen  by  the  SEISP  after  careful 
consideration  of  an  alternative  approach  which  would  begin 
with  decentralization.  Decentralization  would  allow  rapid 
startup  because  centers  of  activity  could  be  established  in 
proximity  to  talent  pools.  But  the  approach  was  rejected 
because:  a  decentralized  Institute  may  exhibit  an  unrealistic 
view  of  its  own  size;  the  staff  requirement  may  be  greater  than 
for  the  centralized  Institute#  distributing  Institute  func¬ 
tions  tends  to  dilute  prestige  and  visibility;  distribution  of 
resources  tends  to  diffuse  effective  leverage  on  a  local  indus¬ 
try/political  base;  and  a  decentralized  Institute  will  inevi¬ 
tably  lack  unity  of  purpose. 


5.2  LOCATION 


The  SEISP  recommends  that  the  following  criteria  guide  the 

choice  of  the  Institute's  location: 

•  Proximity  to  a  major  university  and  to  ready  sources  of 
professional  and  support  staff  candidates 

•  Ready  availability  of  physical  plant*  facilities  and  ser¬ 
vices 

•  Sufficient  attractiveness  to  enable  recruitment  of  high 
level  professionals  from  other  areas 
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•  Proximity  to  a  major  metropolitan  area  and  transportation 
hub 

•  Security  from  external  sources  of  interference  and  intru¬ 
sion 

•  Separation  from  sources  of  day-to-day  political  and  organ¬ 
izational  pressures 

Choice  of  location  will  affect  the  Institute's  opportunities 
for  early  success.  There  must  be  ready  access  to  users*  sup¬ 
pliers*  researchers  and  developers.  Since  software  engineer¬ 
ing  is.  a  rapidly-evolving  discipline*  free  and  convenient 
collaboration  with  experts  in  the  field  is  essential.  High 
caliber  management  and  technical  staff  must  be  attracted  to  the 
Institute*  preferably  not  all  from  long  distances. 


5.3  FUNCTIONAL  RELATIONSHIPS 


The  SEISP  recommends  that  the  Institute's  formal  functional 
relationships  conform  with  the  following  criteria! 

•  Institute  oversight  at  a  OoD  policy  level 

•  Technical  policy  guidance  at  a  OUSO  level 

•  Institute  contract  and  funding  administration  at  a  Service 
level 

•  OoD  technology  Insertion  policy  guidance  at  a  Joint  Logis¬ 
tics  Commanders  level 

•  Industrial  technology  insertion  policy  guidance  at  an  "In¬ 
dustry  Advisory  Council"  level 

•  "Board  of  Visitors"  assessment  of  accomplishments 

The  DoO  Computer  Software  and  Systems  (CSS)  Directorate  will 
provide  a  focal  point  for  DoD  oversight  of  the  Institute.  CSS 
will  be  the  Institute's  principal  advocate  and  sponsor.  CSS 
will  provide  planning*  programming  and  budgeting  support  and 
guidance*  and  interfaces  to  OSD  elements*  other  Government 
agencies*  the  Secretary  of  Defense,  the  Defense  Science  Board* 
the  Congress  and  the  White  House.  CSS  will  also  coordinate  the 
Services'  STARS  activities  with  respect  to  the  Institute. 

The  Institute's  contract  and  flow  of  funding  will  be  adminis¬ 
tered  by  a  lead  Service*  which  will  also  coordinate  requests 
from  program  offices  and  contractors  for  technical  assistance. 
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A  Board  of  Visitors  will  ba  appointed  by  DoD*  composed  of  dis¬ 
tinguished  technical  leaders  from  universities*  industry  and 
Government  to  assess  the  accomplishments  of  the  Institute. 


5.4  START-UP  STRATEGY 


The  SEISP  explored  four  basic  alternative  strategies  together 
with  variations  and  combinations  for  applicability  to  the 
startup  of  the  Institute! 

•  Competitive  --  Initiate  the  Institute  by  issuing  an  RFP  for 
its  creation . 

•  Special  Legislation  —  Through  an  Act  of  Congress*  estab¬ 
lish  the  Institute  as  an  FCRC. 

•  Invite  Initiation  by  FCRC  --  Fund  an  FCRC  to  establish  the 
Institute . 

•  Sole  Source  (not  FCRC)  —  Fund  a  qualified  organization 
(other  than  an  FCRC)  to  establish  the  Institute. 

Competitive  initiation  of  the  Institute  tends  to  satisfy  con¬ 
gressional  concerns*  stimulate  concessions  and  leverage  from 
the  competitive  bidders*  and  enhance  public  awareness  and  the 
visibility  of  the  Institute.  But  there  are  several  serious 
drawbacks  to  the  competitive  alternative.  First,  the  goals  of 
the  Institute  might  be  obscured  in  the  clamor  for  winning  the 
competition.  The  nature  of  the  competitive  cycle  might,  by 
Itself*  discourage  participation  —  thus*  possibly  eliminating 
good  choices  for  Institute  location  and  Director  from  consid¬ 
eration.  Also*  competitive  procurements  are  time-consuming. 
The  time  criticality  of  the  Institute's  mission  may  make  an 
extended  procurement  period  intolerable. 

Legislative  creation  of  the  Institute  legitimizes  the  organ¬ 
ization  and  enhances  its  visibility.  Furthermore*  a  high 
degree  of  stability  is  provided.  However*  the  legislative  sol¬ 
ution  process  may  be  time-consuming  and  will  certainly  extract 
quid  pro  quo  from  the  Services. 

Contract  aJ.  the  Institute  ££  in  FCRC  will  accommodate  quick 
sole-source  funding.  An  FCRC  could  probably  be  persuaded  to  be 
flexible  in  selecting  staff  and  a  director  and  in  setting  of 
operational  policy  and  procedures.  Certain  risks  accrue  to  the 
image  of  the  Institute  through  association  with  an  FCRC. 
FCRC's  provide  minimal  public  visibility.  Existing  FCRC's 
exhibit  forms  of  institutional  bias  (real  or  perceived)  that 
would  color  the  operation  of  the  Institute.  There  is  the  risk 
that  the  Institute  might  attempt  to  operate  in  the  "reflected 
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glory"  of  a  prestigious  FCRC  instead  of  quickly  establishing 
its  own  credentials. 

A  sole  source  contract  (not  in  FCRC )  has  many  of  the  seme  advan¬ 
tages  as  contracting  to  an  FCRC.  Additionally .  a  prestigious 
setting  for  the  Institute  providing  public  visibility  can  be 
selected.  However?  institutional  bias  and  conflict  of  inter¬ 
est  are  possible  drawbacks.  Also ?  a  large  sole-source  award 
may  require  legislative  approval. 

The  SEISP  recommends  that  speed  be  the  primary  consideration  in 
selecting  a  startup  strategy.  The  need  for  the  Institute  is 
critical)  it  must  be  established  in  the  shortest  possible  time. 
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6.0  CONCEPTS  OF  INSTITUTE  OPERATIONS 


Software  Engineering  Institute  operations  will  require  closer 
cooperative  interactions  with  at  least  five  distinct  communi¬ 
ties  whose  interests  and  operating  structures  are  dissimilar 
in  basic  wayst 

•  the  Department  of  Defense 

•  DoD  contractors 

■  commercial  software  and  equipment  manufacturers 

•  academic  and  research  organizations 

•  commercial  software-intensive  computer  resource  users 

The  targets  of  technology  insertion  are  the  DoD  contractors  who 
develop  MCCR  software  and  the  DoD  organic  staffs  who  operate 
and  support  the  software.  Potentially  useful  technology  can 
come  from  any  of  the  five  communities  or  from  the  Institute 
itself.  Commercial  enterprises  whose  businesses  are  complete¬ 
ly  unrelated  to  software  may  be  a  rich  source  of  Internally 
developed  technology.  Many  potential  sources  may  have  no  know¬ 
ledge  of  DoO  software  needs  nor  channels  of  communication  with 
DoD  in  their  normal  business  operations. 

The  Institute  must  YiaOCqualY  search  £&£  g.QUrcag  2d  technolo¬ 
gy  .  As  a  standard  part  of  its  operations*  the  Institute  must 
establish  and  maintain  visible  and  effective  communications 
with  all  elements  of  the  U.S.  Industrial  complex  and  the  DoD 
that  are  concerned  with  the  development  and  operation  of  com¬ 
plex  software  systems. 

The  Institute  must  employ  lf.JLacUy.fl  technology  acquisition 
or actlces .  A  comparison  of  DoD  versus  commercial  aggregate 
softwar'e  expense  (guessed  at  perhaps  li20)  suggests  that  a 
wealth  of  technology  may  reside  in  enterprises  that  normally 
have  no  contact  with  MCCR  procurement.  Institute  operations 
must  match  acquisition  practices  to  the  normal  business  prac¬ 
tices  of  diverse  sources*  rather  than  attempt  to  force-fit  to 
existing  MCCR  procurement  policies. 

The  Institute  must  bflptitriP  technology  insertion.  A  signif¬ 
icant  part  of  the  Institute's  activity  will  be  the  development 
and  adaptation  of  naseent  technologies  to  produce  scaled*  pro¬ 
duction  quality  facilities  for  MCCR  development  and  support. 
As  a  principal  source  of  these  facilities*  the  Institute  will 
be  a  critical  first  link  in  the  chain  leading  to  revolutionary 
improvements!  it  must  establish  impressive  schedules  and  pro¬ 
ductivities  of  its  own  through  first  use  of  the  technologies  it 
develops  to  prove  their  effectiveness  to  the  MCCR  community. 


Concepts  of  Institute  Operations 


20 


The  Institute  must  employ  rasults-oriantad  technical  manage¬ 
ment  practices .  The  Institute's  effectiveness  will  be  meas¬ 
ured  by  the  superiority  that  software-intensive  U.S  mission 
critical  systems  establish  and  maintain.  All  Institute  oper¬ 
ations  must  be  guided  by  a  priority  system  that  places  high 
value  on  operational  results. 

The  Institute  must  establish  J,  senior  management  voice  in  Con¬ 
gressional*  DoD  and  Service  MCCR  policy  deliberations  and 
decisions.  The  availability  of  new  production  quality  soft¬ 
ware  technology  is  no  guarantee  that  the  technology  will  be 
effectively  applied.  The  challenge  of  technology  insertion  is 
seldom  a  wholly  technical  challenge.  Impediments  may  reside  in 
programmatic*  jurisdictional  *  organizational  and  procedural 
considerations  to  which  the  Institute  can  bring  a  broad*  unbi¬ 
ased  and  results-oriented  perspective. 


As  the  central  focal  point  of 
nlties  --  OoO*  DoD  contractors 
varsities  and  researcher  and 
--  the  Institute  will  provide 
cations  and  leverage  point  for 


the  five  diverse  software  commu- 
*  commercial  manufacturers*  uni- 
large  commercial  software  users 
a  valuable  service  as  a  communi- 
the  STARS  program  as  a  whole. 
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7.0 


ESTIMATES  OF  REQUIRED  RESOURCES 


"ive  year  staffing  projections  are  as  follows:  80,  130,  180, 
220  and  250.  These  numbers  represent  the  total  number  of  SEI 
staff  to  be  in  place  at  the  end  of  each  respective  year;  total 
staff  years  used  for  budget  projections  will  be  something  less 
than  the  above  numbers.  The  SEISP  believes  that  this  projected 
buildup  can  be  achieved  and  must  be  pursued  in  order  for  the 
Institute  to  achieve  its  objectives.  The  number  250  does  not 
represent  a  fixed  ceiling.  Rather,  it  is  the  SEISP’s  estimate 
of  the  minimum  in-house  staff  required  to  sustain  operations. 
Any  additional  personnel  resources  required  would  be  obtained 
via  contract  and  other  means. 

Based  on  the  5  year  projection  for  resources,  a  5  year  project 
baseline  dollar  estimate  of  #8M,  *12h,  $15M,  *20M,  and  *20M  has 
been  derived . 


After  the  first  year  of  operation,  the  baseline  funding  falls 
short  of  the  total  required  for  the  Institute.  (The  differ¬ 
ences  by  year  between  the  total  and  the  baseline  are  *3M,  * 5M , 
♦  8M,  ♦ 1 3M  starting  at  year  2.)  The  differential  funding  is  to 
come  directly  from  the  Services  for  products  and  services  pro¬ 
vided  by  the  Institute  in  response  to  specific  needs.  A  cost 
model  of  an  existing  non-profit  corporation  was  used  to  project 
the  dollar  requirements. 


A  list  of  assumptions  and  a  5  year  pro  forma  cost  analysis  is 
contained  in  Appendix  B  along  with  a  personnel  resource  analy¬ 
sis  and  allocation  of  personnel  by  major  functions. 
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8.0  UNRESOLVED  ISSUES 


The  SEISP  was  unable  to  completely  resolve  three  issues. 
Although  all  are  ultimately  critical  to  the  successful  attain¬ 
ment  of  the  Institute's  goals*  none  is  critical  to  its  success¬ 
ful  initiation. 

*  Protection  of  proprietary  rights 

*  Protection  of  militarily  critical  technical  data 

*  Relationship  with  industry 

Tha  issue  of  the  protection  of  proprietary  rights  in  data  and 
its  impact  on  the  success  of  the  Institute  is  being  addressed 
by  a  Rights  in  Data  Technical  Working  Group  CRDTWG)  recently 
established  by  IDA.  The  RDTWG's  report  will  be  delivered  to 
the  DoD  by  October  and  should  address  those  data  rights  issues 
of  concern  to  the  Institute. 

The  issue  of  the  protection  of  militarily  critical  data  is  pre¬ 
sently  under  study  by  joint  Government-industry  teams  in  con¬ 
nection  with  the  OoD  funded  Export  Control  Project  at  IDA. 
These  teams  are  addressing  areas  of  interest  to  the  Institute. 

The  SEISP  consensus  is  that  to  be  effective  the  Institute  must 
have  an  intense*  continuing  relationship  with  industry.  This 
includes  sharing  of  personnel*  sharing  of  technology*  joint 
efforts*  and  funding.  No  acceptable  plan  for  creating  and  sus¬ 
taining  such  a  relationship  was  developed.  Although  direct 
partial  funding  of  the  Institute  by  industry  was  rejected* 
investment  by  industry  of  personnel  resources  and  facilities 
is  desirable  if  such  Investments  do  not  negatively  affect  the 
Institute's  responsiveness  to  DoD  needs. 
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APPENDIX  A 


SOFTWARE  ENGINEERING  INSTITUTE  STUDY  PANEL 

Chairman:  Mr.  Neil  S.  Eastman 

~  Mr.  Neil  S.  Eastman,  Manager  of  the  Software  Engineering 
and  Technology  function  of  IBM's  Federal  Systems  Division 
(FSD)  served  as  Chairman  of  the  Software  Engineering  insti¬ 
tute  (SEI)  Study  Panel.  Mr.  Eastman  has  been  in  the  Soft¬ 
ware  Engineering  field  for  the  past  22  years,  pioneering 
work  in  Advanced  Software  Engineering  (SE)  areas.  He  has 
held  numerous  software  management  positions  on  large  DOD 
contracts  and  has  worked  on  software  metrics,  software  de¬ 
sign  methodologies  and  the  automation  of  software  processes 
in  FSD.  Currently,  he  is  responsible  for  software  methods 
and  practices  as  employed  by  over  2,000  software  profes¬ 
sionals  and  FSD's  Advanced  Technology  Program  in  the  field 
of  Software  Engineering. 

Executive  Secretary:  Dr.  Robert  H.  Fox 

Dr.  Robert  H.  Fox,  Past  Director,  Science  and  Technology 
Division  (STD) ,  Institute  for  Defense  Analyses  (IDA) , 
served  as  Executive  Secretary  of  the  SEI  Panel.  Dr.  Fox 
worked  in  the  area  of  Military  Science  and  Technology  from 
1950  until  his  retirement  in  1983.  As  Director  of  STD,  he 
played  an  active  role  in  the  direction  of  studies 
concerning  the  applications  of  computer  technology  (both 
hardware  and  software)  within  the  Department  of  Defense. 

Panel  Members : 

Dr.  Roger  R.  Bate 

Dr.  Bate  is  the  Director  of  the  Computer  Science  Lab  at 
Texas  Instruments,  Inc.  (TI)  .  He  is  responsible  for  re¬ 
search  conducted  in  the  areas  of  Artificial  Intelligence, 
speech  processing,  computer  architectures,  images,  langu¬ 
ages  and  programming  environments.  Prior  to  this.  Dr. 
Bate  was  responsible  for  the  improvement  of  software  pro¬ 
ductivity  with  TI.  Dr.  Bate  was  a  member  of  the  faculty  at 
the  Air  Force  Academy  where  he  was  head  of  the  Astronautics 
and  Computer  Science  Department  and  Vice  Dean  of  the  Fac¬ 
ulty.  Dr.  Bate  chaired  the  Computer  Technology  Forecast 
and  Weapon  Systems  Impact  Study,  COMTEC-2000,  which  had  a 
significant  impact  on  Air  Force  policies  concerning  com¬ 
puters  of  the  future. 

Dr.  Richard  A.  DeMillo 

Dr.  DeMillo  is  a  Professor  in  the  School  of  Information  and 
Computer  Science  at  the  Georgia  Institute  of  Technology. 
He  is  the  principle  investigator  for  STEP  contracts.  He 
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teaches  and  conducts  research  in  Software  Engineering,  Com¬ 
puter  security,  and  computer  science.  Dr.  DeMillo  has 
served  as  a  technical  consultant  to  U.S.  government 
agencies  and  private  organizations  on  such  diverse  topics 
as  computer  security,  software  technology,  commercial  ap¬ 
plications,  software  development,  and  trade  secret  protec¬ 
tion  for  proprietary  software.  In  the  area  of  software  en¬ 
gineering,  he  has  concentrated  on  software  reliability  and 
the  emerging  area  of  software  metrics. 

Joseph  M.  Pox 

Mr.  Fox  is  Chairman  of  Software  A&E,  a  software  fii.m  spe¬ 
cializing  in  software  engineering  and  artificial  products 
and  services.  He  chaired  the  Navy  Embedded  Computer  Review 
Panel  for  the  Assistant  Secretary  of  the  Navy  and  was  a 
member  of  the  DoD  Instruction  Set  Architecture  Panel  and 
the  DoD  Defense  Science  Ad  Hoc  Committee  on  Embedded  Com¬ 
puters.  Prior  to  his  work  at  Software  A&E,  Mr.  Fox  was 
Vice  President  of  the  Federal  Systems  Division,  managing 
the  largest  group  of  programmers  in  IBM. 

Dr.  Richard  J.  Gowen 

Dr.  Gowen  is  Vice  president  and  Dean  of  Engineering  at  the 
South  Dakota  School  of  Mines  and  Technology  (SDSM&T) .  At 
SDSM&T,  he  has  applied  his  professional  experiences  to  the 
development  of  new  approaches  to  quality  engineering  and 
scientific  education.  Prior  to  this.  Dr.  Gowen  was  a  mem¬ 
ber  of  the  Air  Force  Academy  faculty,  where  he  lead  the  de¬ 
velopment  of  the  B.S.  EE  and  initiated  the  sponsored  re¬ 
search  program.  He  developed  and  directed  the  NASA-DoD 
Space  Medical  Instrumentation  Laboratory  to  provide  engi¬ 
neering  and  scientific  support  to  aerospace  and  electronics 
industries  during  the  NASA  Apollo  and  Skylab  programs.  Dr. 
Gowen  serves  as  an  advisor  and  consultant  to  government  and 
industry  and  is  the  1984  IEEE  president. 

Dr.  John  H.  Manley 

Dr.  Manley  is  president  and  founder  of  Computing  Technology 
Transition,  Inc.,  a  young  consulting  firm  which  provides 
software  engineering  consultation  primarily  to  government 
agencies.  He  is  also  Vice-President  for  Engineering  and 
Technology  for  NASTEC  Corporation  where  his  primary  respon¬ 
sibilities  are  providing  strategic  planning  and  technical 
marketing  direction  for  a  full  line  of  computer-aided  sys¬ 
tems  and  software  engineering  products.  Dr.  Manley  is  a 
recognized  authority  in  software  engineering  with  nearly  30 
years  of  experience  in  industry,  government  and  academia. 
Prior  to  his  present  work,  Dr.  Manley  was  Corporate  Direc¬ 
tor  for  Programming  Applied  Technology  at  ITT  where  he  was 
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responsible  for  program  technology  worldwide.  Dr.  Manley 
also  spent  20  years  in  the  Air  Force  and  was  Assistant  to 
i  the  Director  of  the  Applied  Physics  Lab  at  Johns  Hopkins 

University  as  well  as  a  visiting  professor  in  the  EE  De¬ 
partment  at  the  university. 

Mr.  Alfred  M.  Pietraaanta 

Mr.  Pietrasanta,  as  Director  of  the  IBM  Software  Engineer- 
<  ing  Institute,  is  responsible  for  a  curriculum  of  courses 

on  modern  software  engineering  and  computer  science  being 
offered  to  the  IBM  systems  programming  professionals.  A 
major  focus  of  the  Software  Engineering  institute  is  on 
software  design  methodology  to  achieve  high  quality  and 
productivity.  Mr.  Pietrasanta  is  also  responsible  for  the 
New  Technical  Higher  Education,  which  will  provide  several 
education  courses  to  new  professionals  in  IBM  labs  and 
plants  during  their  first  18  months  after  hire. 

Dr.  Sam  Steppe 1 

Dr.  Steppel  is  the  senior  member  of  the  executive  staff  at 
Computer  Sciences  Corporation  (CSC) .  He  is  on  the  staff  to 
the  President,  CSC  Systems  Group  and  has  oversight  of  the 
system  development  efforts  within  this  group.  He  is  the 
coordinator  of  the  CSC  Technology  Task  Force  which  analyzes 
new  technology  and  its  impact  on  computer  system 
development.  Dr.  Steppel  has  been  tracking  new  technology 
advancements,  such  as  STARS  and  Ada,  and  directing  the  pre¬ 
paration  of  CSC's  comprehensive  system  development  method¬ 
ology.  With  over  12  ,  jars  of  experience  in  developing  com¬ 
puter-based  systems,  past  experiences  include  the  design 
and  development  of  systems  for  NASA  and  managing  a  NASA 
facility.  Dr.  Steppel  was  also  employed  by  Stanford  Uni¬ 
versity  and  the  European  Center  for  Nuclear  Research. 

Mr.  Keith  Qncapher 

Mr.  Uncapher  is  Executive  Director  of  the  Information 
Sciences  Institute  (ISI) ,  Associate  Dean  in  the  School  of 
Engineering,  and  Professor  of  Computer  Science  at  the  Uni¬ 
versity  of  Southern  California  (USC) .  Mr.  Uncapher  is  the 
founder  and  director  of  the  ISI,  which  has  become  one  of 
the  country's  four  leading  university-based  Information 
Processing  Research  Centers.  It  provides,  within  a  univer¬ 
sity,  a  systems-or iented  problem  solving  research  environ¬ 
ment,  with  expertise  in  the  application  of  information 
processing  science  and  technology,  to  major  user  areas. 

Dr.  Barry  H.  Whalen 

Dr.  Whalen  is  President  of  WAFER  TEC,  a  hardware  company 
that  is  applying  advance  integrated  circuit  technology  to 
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high  performance  small  computers.  Prior  to  this,  Dr.  Whalen 
spent  20  years  at  TRW.  As  VHSIC  Project  Manager,  he  was 
responsible  for  the  definition  and  design  of  very  high 
integrated  circuits  and  brass  board  processors.  Dr.  Whalen 
was  responsible  for  planning  and  marketing  advance 
technology  for  computers,  communication  and  electronic 
warfare  when  he  was  Special  Assistant  to  the  General 
Manager,  Military  Electronics  Division,  TRW.  Other 
accomplishments  include:  manager  of  software  development 
projects  for  the  Gemini  and  Apollo  spacecrafts  and  several 
military  satellite  systems;  developed  the  Vernier  guidance 
software  for  the  Atlas  ICBM;  and  member  of  the  National 
Materials  Advisory  Board  on  VHSIC. 

Dr.  Charles  H.  Wilcox 

Dr.  Wilcox  has  been  with  Hughes  Aircraft  for  30  years. 
During  the  first  15  years,  he  worked  at  the  Hughes  Corpo¬ 
rate  Research  Labs  conducting  Artificial  Intelligence  re¬ 
search.  Later  he  served  as  Director  of  IR&D  for  the  total 
company  and  then  as  Director  of  Engineering  for  the  Aero¬ 
space  Group.  Dr.  Wilcox  is  presently  the  Corporate  Direc¬ 
tor,  Technical  Management,  where  he  provides  company 
leadership  and  oversight  for  software  engineering  and 
CAD/CAM  at  Hughes.  He  also  coordinates  the  military 
requirements  planning  for  the  total  company  and  has  served 
on  several  other  panels  for  the  government. 

Dr.  william  Wulf 

Dr.  Wulf  is  one  of  the  founders  and  President  of  Tartan 
Laboratories.  This  relatively  new  company  is  involved  in 
the  development  of  high  technology  software.  Specifically, 
system  software  that  is  intended  to  enhance  programmer  pro¬ 
ductivity,  including  compilers,  editors,  debuggers,  pro¬ 
files,  etc.  Formerly  a  professor  of  computer  science  and 
acting  department  head  at  Carnegie-Mellon  University  (CMU) , 
Dr.  Wulf  was  responsible  for  the  design  of  BLISS  (a  systems 
programming  language),  C.mmp  (a  16-processor  multi-proces¬ 
sor)  ,  hydra  (a  capability-based  operating  system  with  em¬ 
phasis  on  utilizing  parallellism  in  C.mmp  and  on  protection 
and  security)  and  Alphard  (a  programming  language  with  em¬ 
phasis  on  data  abstraction  and  program  verification). 


DoD  STEERING  COMMITTEE 
Dr.  Edward  Lieblein 

Acting  Director  (Computer  Software  &  Systems) , 
ODUSD  (R&AT) 

(Study  Monitor) 
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Colonel  J.  Frank  Campbell,  USA 
Headquarters,  DARCOM  (DRCDE-SB) 

Lt.  Colonel  Larry  E.  Druffel 
Special  Assistant  to  DUSD  (R&AT) 

Mr.  Robert  M.  Hlllyer 

Director  of  Navy  Labor ator ies/NAVMAT-05 

Dr.  Bernard  Kulp 
Headquarters,  AFSC/DLZ 
Andrews  AFB 

Major  General  Emmett  Paige,  Jr. 

Commanding  General 
Headquarters,  U.S.  Army 

Electronics  Research  &  Development  Command 


INSTITUTE  FOR  DEFENSE  ANALYSES 

Mr.  Norman  D.  Jorstad 

Mr.  Jorstad  is  a  Research  Staff  Member  in  the  Science  and 
Technology  Division  of  the  Institute  for  Defense  Analyses 
(IDA).  His  expertise  in  export  control,  system  integration 
and  design  of  computers,  teleprocessing,  communication  and 
command  and  control  systems  has  influenced  many  IDA  reports 
and  papers.  Presently,  Mr.  Jorstad  is  developing  a  plan 
for  the  improvement  of  DoD  acquisition  procedures.  Before 
coming  to  IDA,  Mr.  Jorstad  was  president  and  principal 
consultant  for  JORAD  Associates. 

Professor  Thomas  C.  Bar tee 

Professor  Bartee  is  on  the  teaching  staff  of  the  Aiben 
Computation  Lab  at  Harvard  University  in  the  Department  of 
Engineering  and  Applied  Physics.  As  a  consultant  to  the 
Institute  for  Defense  Analyses,  Professor  Bartee  was  on  the 
President's  Commission  on  Law  Enforcement  and 
Administration  of  Justice,  Technical  Subcommittee,  studying 
data  processing  systems  for  the  Department  of  Justice.  At 
IDA,  he  also  participated  in  several  studies  of  computer 
networking,  especially  concerned  with  protocols,  system 
organization  and  distributed  processing. 

Dr.  Thomas  H.  Probe rt 

Dr.  Probert  is  Director  of  the  newly  established  Computer 
and  Software  Engineering  Division  at  the  Institute  for 
Defense  Analyses.  Dr.  Probert  has  been  actively  involved 
with  the  Ada  Joint  Program  Office  since  1981  and  with  the 
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STARS  Program  Office  since  its  establishment.  Dr.  probert 
was  responsible  for  the  establishment  of  the  Ada  Validation 
Organization  at  IDA  and  has  played  the  major  role  in 
developing  and  leading  the  growing  IDA  program  aimed  at 
providing  the  DoD  and  the  relevant  computing  community  the 
technical  assessment  and  support  necessary  to  maintain 
international  leadership.  Prior  to  joining  IDA,  Dr.  Probert 
was  a  Technical  Staff  Member  at  the  MITRE  Corporation, 
where  he  was  responsible  for  the  development  of  the 
methodology  for  validating  Ada  compiler  for  the  DoD. 


APPENDIX  B 


SEI  RESOURCE  JUSTIFICATION 
LIST  OF  ASSUMPTIONS 
SEI  COST  ANALYSIS* 


I.  Staffing 

A.  Level  based  on  midyear  staffing  each  year: 

(year  1:  42;  year  2:  105;  year  3:  156; 

year  4:  201;  year  5:  237) 

B.  Ratio  2  senior  research  personnel  to  1  support 

personnel 


c. 

Salary 

Year  1 

Year  2 

Year  3 

Year  4 

Year  5 

Senior 

60K 

55K 

55K 

60K 

6SK 

Support 

25K 

27K 

29K 

31K 

33K 

Estimates  are  based  on  the  initial  hire  of  very  high  level 

people.  Cost-of-living  is  incremented  at  approximately  8 %/year. 

D.  Fringe  Benefit  Rate  -  22%  of  salaries  each  year  (not 
including  paid  vacation) . 

II.  Other  Direct  Costs  (includes  6%  COL) 

A.  Travel,  materials  and  supplies  per  senior  personnel. 

B.  Common  costs  as  a  percentage  of  total  salaries  (categories 
include  materials  and  supplies,  travel,  communications). 

C.  Administrative  costs  which  include  a  percentage  of 
administrative  salaries,  and  related  space,  travel  and 
material  and  supplies  costs. 

III.  Indirect  Costs 

A.  Overhead  rate  -  37%  each  year. 


The  particular  cost  parameters  given  (e.g.  overhead)  relate  to  a 
specific  accounting  system  which  varies  from  organization  to 
organization.  However,  total  cost  derived  is  relatively  invariant 
to  changes  in  accounting  systems. 


B-l 


IV.  Facility  Costs 

A.  General  workspace  based  on  percentage  of  salaries 
at  a  rate  of  $2/sq.  ft. /month  (includes  a  library, 
classrooms,  conference  rooms  and  laboratories). 
(Total  space  of  70,000  sq.  ft.  in  year  5.) 

B.  impute r  support  -  includes  operations  and  main¬ 
tenance  .costs,  and  equipment  amortization  costs 
at  20%/per  year. 

C.  Network  operations  ?■  d  maintenance  -  an  estimate 
of  the  costs  involved  per  year  (includes  6%  COL 
each  year) . 

V.  Startup/Expansion  Costs 

A.  Computer  room  buildout  -  only  a  startup  cost. 

B.  Laboratory  buildout  -  based  on  general  workspace 
dollars. 

C.  Network  equipment  acquisition  costs  -  an  estimate 
of  the  initial  expense  required. 

D.  Office  equipment  and  furniture  -  based  on  S2K  per 
new  hire. 

E.  Computer  equipment  acquisition  -  based  on  $40K  per 
senior  new  hire  and  $30K  per  support  new  hire,  plus 
the  cost  of  $1KL  (years  1-3)  and  $2KL  in  years 

4  and  5. 

F.  Equipment  installation  -  based  on  an  estimate  for 
phone  system,  copiers  and  terminal  installation. 

G.  Personnel  relocation  -  50%  of  senior  new  hires 
would  be  relocated. 
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SOFTWARE  ENGINEERING  INSTITUTE 
PRO  FORMA  COST  ANALYSIS 
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PERSONNEL  RESOURCE  ANALYSIS 


Year  5 


Total  Headcount 

Indirect  (one  third)' 
Direct  (two-thirds) 


Directs  by  Major  Function 

Technology  Insertion  (60%) 
Technical  Support  (20%) 
Education/Training  (10%) 
Research  (10%) 


Directs  on  Technology  Insertion 

Identify,  Select  Technology 
3  Pilot  Projects  @  20 
3  Evaluations,  Qualifications  @  5 
Demonstrate,  Market 


Notes : 

A 

Indirect  percentage  based  on  some  comparable  laboratory 
examples.  Consists  of  managers,  secretaries,  administration, 
computing  center. 

O 

Percentages  of  effort  by  major  function  are  approximate. 


’This  is  an  example  only  of  Technology  Insertion  activities, 
to  illustrate  approximate  levels  of  effort  that  might  be 
anticipated.  Pilot  projects  consist  of  technology 
re-engineering,  testing,  scale-up,  validation,  methodology 
definition,  etc. 


APPENDIX  C 


INSTITUTIONAL  TYPES  CONSIDERED 


A  sv_  _y  of  the  features  of  the  five  existing  institu¬ 
tions  sel&cted  by  the  Panel  for  further  examination  is  con¬ 
tained  in  this  section.  These  institutions  are: 


o  Lincoln  Laboratory  (LL)  -  University  based, 
Tri-Service 

o  Naval  Research  Laboratory  (NRL)  -  Navy-Corporate 
laboratory 

o  National  Center  of  Atmospheric  Research  (NCAR)  - 
University-consortium 

o  Electromagnetic  Compatibility  Analysis  Center  (ECAC) 
Joint  Service-non-profit  technical  support 

o  Applied  Research  Laboratory  (ARL)  -  Navy-University 
laboratory 
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LINCOLN  LABORATORY 


FEATURES : 


o  University  component,  strong  coupling  at  top 
management  level 

o  Tri-Service  and  DARPA  overall  program  review 
and  direction 

o  Advanced  electronics  R&O  mission 

o  Strong  emphasis  on  staff  quality 

o  Both  hardware  and  software  products 

o  Many  individually  contracted  efforts  for  Service 
elements 

o  Not  exposed  to  on-campus  student  and  faculty 
politics 

DOES  NOT: 

o  Have  industry  support  functional  involvement 
o  Interface  functionally  with  unversity  community 


NAVAL  RESEARCH  LABORATORY 


FEATURES: 


o  Navy  corporate  R&D  organization 

o  Annual  review  by  Naval  Research  Advisory  Committee 
o  Industrial  funding,  competes  within  Navy  for  funds 
o  Sensitive  to  needs  of  systems  commands 

o  Technical  review  primarily  internal 

o  Primary  emphasis  on  R&O 


DOES  NOT: 

o  Have  strong  university  involvement 

o  Have  strong  industry  involvement 

o  Have  ready  access  to  high-level  slots 


NATIONAL  CENTER  FOR  ATMOSPHERIC  RESEARCH 


FEATURES : 


o  Operated  by  university  consortium  non-profit 
corporation 

o  Challenging  mission 

o  Parent  organization  consists  of  entire  atmos¬ 

pheric  research  community 

o  Parent  organization  has  delegated  responsibility 

from  NSF  for  major  portion  of  NSF  atmospheric 
research  program 

o  Research  focus 


DOES  NOT! 

o  Support  military  needs,  except  indirectly 

o  Functionally  involve  industry 

o  Concern  itself  with  technology  insertion 


C-4 


ELECTROMAGNETIC  COMPATIBILITY  ANALYSIS  CENTER 


FEATURES : 

o  High  level  OSD  program  oversight 

o  Tri-Service  technical  management,  staffing 

o  DoD-wide  responsibilities 

o  Strong  technical  support  from  non-profit 

organisation 

o  Interactive  tasking  by  Service  Program  office 

o  Full  cost  reimbursement  by  users 

o  Base  funding  to  maintain  capabilities 

o  Emphasis  is  analysis  and  software,  large  model 

development 

DOES  NOT: 

o  Have  university  involvement 

o  Have  industry  involvement 

o  Have  emphasis  on  technology  insertion 


APPLIED  RESEARCH  LABORATORY 


FEATURES : 

o  University  component,  not  degree-granting 

o  Broad-based  University  Advisory  Board,  sponsor 
participation 

o  Close  involvement  with  university 

o  Industrially-funded  program,  primarily  for  Navy 

o  Emphasis  on  technology  base  advancement 

o  Limited  industrial  support,  with  sponsor 
permission 

o  Emphasis  on  staff  quality 

o  Both  hardware  and  software  products 

DOES  NOT: 

o  Have  multi-university  involvement 

o  Have  Tri-Service  emphasis 

o  Have  technology  insertion  emphasis 

Have  large  industry  involvement 


o 


